home *** CD-ROM | disk | FTP | other *** search
/ Ian & Stuart's Australian Mac: Not for Sale / Another.not.for.sale (Australia).iso / fade into you / being there / Issues & Ideas / VMRL / Concepts / pesce-www next >
Text File  |  1994-10-01  |  24KB  |  470 lines

  1.  
  2.    
  3.    
  4.                                   CYBERSPACE
  5.                                        
  6.    
  7. Mark D. Pesce, Peter Kennard and Anthony S. Parisi
  8. Labyrinth Group
  9. 45 Henry Street #2
  10. San Francisco, CA 94114
  11. mpesce@netcom.com peterk@netcom.com dagobert@netcom.com
  12.  
  13.    
  14.    
  15. Abstract
  16.  
  17.    
  18.    
  19.    This work describes a visualization tool for WWW, "Labyrinth", which
  20.    uses WWW and a newly defined protocol, Cyberspace Protocol (CP) to
  21.    visualize and maintain a uniform definition of objects, scene
  22.    arragement, and spatio-location which is consistent across all of
  23.    Internet. Several technologies have been invented to handle the
  24.    scaling problems associated with widely-shared spaces, including a
  25.    distributed server methodology for resolving spatial requests. A new
  26.    languague, Virtual Reality Markup Language (VRML) is introduced as a
  27.    beginning proposal for WWW visualization.
  28.    
  29. Introduction
  30.  
  31.    
  32.    
  33.    The emergence, in 1991, of the World Wide Web, added a new dimension
  34.    of accessibility and functionality to Internet. For the first time,
  35.    both users and programmers of Internet could access all of the various
  36.    types of Internet services (FTP, Gopher, Telnet, etc.) through a
  37.    consistent and abstract mechanism. In addition, WWW added two new
  38.    services, HTTP, the Hypertext Transfer Protocol, which provides a
  39.    rapid file-transfer mechanism; and the Uniform Resource Locator, or
  40.    URL, which defines a universal locator mechanism for a data set
  41.    resident anywhere within Internet'ís domain.
  42.    
  43.    The first major consequence of the presence of WWW on Internet has
  44.    manifested itself in an explosion in the usability of data sets within
  45.    it. This is directly correlatable to the navigability of these data
  46.    sets: in other words, Internet is useful (and will be used) to the
  47.    degree it is capable of conforming to requests made of it. WWW has
  48.    made Internet navigable, where it was not before, except in the most
  49.    occult and hermetic manner. Furthermore, it added a universal
  50.    organization to the data within it; through WWW, all four million
  51.    Internet hosts can be treated as a single, unified data source, and
  52.    all of the data can be treated as a single, albeit complexly
  53.    structured, document.
  54.    
  55.    It would appear that WWW, as a phenomenon, has induced two other
  56.    processes to begin. The first is an upswing in the amount of traffic
  57.    on Internet (1993 WWW traffic was 3000x greater than in 1992!); the
  58.    second is a process of organization: the data available on Internet is
  59.    being restructured, tailored to fit within WWW. (This is a clear
  60.    example of ìthe medium is the messageî, as the presence of a new
  61.    medium, WWW, forces a reconfiguration of all pre- existing media into
  62.    it.) This organization is occurring at right angles to the previous
  63.    form of organization; that is to say that, previously, Internet
  64.    appeared as a linear source, a unidimensional stream, while now, an
  65.    arbitrary linkage of documents, in at least two dimensions (generally
  66.    defined as ìpagesî), is possible. As fitting the organization skills
  67.    most common in Western Civilization, this structure is often
  68.    hierarchical, with occasional exceptions. (Most rare are
  69.    anti-hierarchical documents which are not intrinsically confusing.)
  70.    
  71.    Navigability in a purely symbolic domain has limits. The amount of
  72.    ìdepthî present in a subject before it exceeds human capacity for
  73.    comprehension (and hence, navigation) is finite and relatively
  74.    limited. Humans, however, are superb visualizers, holding within their
  75.    craniums the most powerful visualization tool known. Human beings
  76.    navigate in three dimensions; we are born to it, and, except in the
  77.    case of severe organic damage, have a comprehensive ability to
  78.    spatio-locate and spatio-organize.
  79.    
  80.    It seems reasonable to propose that WWW should be extended, bringing
  81.    its conceptual model from two dimensions, out, at a right angle, into
  82.    three. To do this, two things are required; extensions to HTML to
  83.    describe both geometry and space; and a unified representation of
  84.    ìspaceî across Internet. This work proposes solutions to both of these
  85.    issues, and describes a WWW client built upon them, called
  86.    ìLabyrinthî, which visualizes WWW as a space.
  87.    
  88. Visualization and VRML
  89.  
  90.    
  91.    
  92.    As of this writing, HTML is capable of expressing both textual and
  93.    pictorial data, and can provide some limited formatting features for
  94.    each of them; beyond this it provides a linkage mechanism to express
  95.    the connection between data sets. HTMLís roots are in text; its
  96.    parent, SGML, specifies a format for printed media, a expression which
  97.    is intrinsically two-dimensional. For this reason, we have stepped
  98.    ìoutsideî of HTML in our language specifications for geometry and
  99.    place, defining a simple, easily parsed scripting language for the
  100.    generation of objects and spaces.
  101.    
  102.    The basic functionality for any three-dimensional language interface
  103.    to WWW can be broken into three parts; object definitions, which
  104.    include the definitions of the geometric representations for these
  105.    objects; scene definitions, which define ìplacementî of these objects
  106.    inside of a larger context; and a mechanism which ìbindsî a URL to an
  107.    object within a scene. The current revision of Labyrinth's Virtual
  108.    Reality Markup Language (VRML), while unsophisticated, does fulfill
  109.    all of these requirements, and therefore provides all of the basic
  110.    functionality required in a fully visualized WWW client.
  111.    
  112.    As currently defined, Labyrinth's VRMLdî files are a unique data type,
  113.    like MPEG or AIFF, and must be integrated with MIME in order to launch
  114.    a companion ìviewerî. This is not an optimal solution; rather, it
  115.    should be possible to extend HTML to encapsulate ìspatialî data types;
  116.    these, then, could be visualized or ignored given the capabilities of
  117.    the WWW client. The OpenGL, OpenInventor, or HOOPS specifications
  118.    could form a basis, insofar as object definitions are concerned, for
  119.    HTML extensions, and should be examined as a possible (and
  120.    well-supported) solution to this issue. Our scripting language should
  121.    serve as a starting example, rather than a proposal for an all-
  122.    inclusive solution.
  123.    
  124.    Any conceptualization of space contains within it, implicitly, the
  125.    quality of number; i.e., ìhow muchî or ìhow farî is contained within
  126.    the simple expression of existence. Space, in its electronic
  127.    representation, is numbered, and, if it is to be shared by billions of
  128.    simultaneous participants, it must be consistent, unique, and very
  129.    large/ dense. Despite this, it is rarely necessary for a WWW client to
  130.    deal with the totality of space; operations occur local to the
  131.    position of the WWW viewer, and this local description of space is
  132.    nearly always a great deal more constrained than the entire spatial
  133.    representation.
  134.    
  135.    It is necessary for VRML to define a numbering system for
  136.    visualization which conforms to the three principles outlined above.
  137.    Another section of this work describes such a system.
  138.    
  139. Cyberspace
  140.  
  141.    
  142.    
  143.    For the purposes of continuity in navigation, it is necessary to
  144.    create a unified conceptualization of space spanning the entire
  145.    Internet, a spatial equivalent of WWW. This has been called
  146.    ìCyberspaceî, in the sense that it has at least three dimensions,
  147.    but exists only as a ìconsensual hallucinationî on the part of the
  148.    hosts and users which participate within it. There is only one
  149.    cyberspace, just as there is only one WWW; to imply multiplicity is to
  150.    defeat the objective of unity.
  151.    
  152.    At its fundamental level, cyberspace is a map that is maintained
  153.    between a regular spatial topology and an irregular network topology.
  154.    The continuity of cyberspace implies nothing about the internetwork
  155.    upon which it exists. Cyberspace is complete abstraction, divorced at
  156.    every point from concrete representation.
  157.    
  158.    All of the examples used in the following explanation of the
  159.    algorithmic nature of cyberspace are derived from our implementation
  160.    of a system that conforms to this basic principle, a system developed
  161.    for TCP/IP and Internet.
  162.    
  163. Metrics in Cyberspace
  164.  
  165.    
  166.    
  167.    Internet defines an address ìspaceî for its hosts, specifying these
  168.    addresses as 32-bit numbers, expressed in dotted octet notation, where
  169.    the general form is {s.t.u.v}. Into this unidimensional address space,
  170.    cyberspace places a map of N dimensions (N = 3 in the canonical,
  171.    ìGibsonianî cyberspace under discussion here), so that any ìplaceî can
  172.    be uniquely identified by the tuple {x.y.z}.
  173.    
  174.    In order to ensure sufficient volume and density within cyberspace, it
  175.    is necessary to use a numbering system which has a truly vast dynamic
  176.    range. We have developed a system of ìaddress elementsî where each
  177.    element contains a specific portion of the entire expressible dynamic
  178.    range in the form:
  179.    
  180.    {p.x.y.z}
  181.    
  182.    where p is the place value, and x, y, and z are the metrics for each
  183.    dimension. The address element is currently implemented as a 32-bit
  184.    construct, so the range of p is ±127, and x, y, and z, are unsigned
  185.    octets. Address elements may be concatenated to any level of
  186.    resolution desired; as most operations in cyberspace occur within a
  187.    constrained context, 32, or at most, 64 bits is sufficient to express
  188.    the vast majority of interactions. This gives the numbering system the
  189.    twin benefits of wide dynamic range and compactness; compactness is an
  190.    essential quality in a networked environment.
  191.    
  192.    This is only one possible numbering scheme; others may be developed
  193.    which conform to the principles as given, perhaps more effectively.
  194.    
  195.    Cyberspace has now been given a universal, unique, dense numbering
  196.    system; it is now possible to quantify it. The first quantification is
  197.    that of existence (metrics); the second quantification is that of
  198.    content. Content is not provided by cyberspace itself, but rather by
  199.    the participants within it. The only service cyberspace needs to
  200.    provide is a binding between a spatial descriptor and a host address.
  201.    This can be described by the function:
  202.    
  203.    
  204.    
  205. f(s) => a
  206.  
  207.    where s is a spatial identifier, and a is an internetwork address.
  208.    
  209.    This is the essential mathematical construction of cyberspace.
  210.    
  211. Implementation of Cyberspace Protocol
  212.  
  213.    
  214.    
  215.    If cyberspace is reducible to a simple function, it can be expressed
  216.    through a transaction-based protocol, where every request yields a
  217.    reply, even if that reply is Δ. In the implementation under
  218.    examination, cyberspace protocol (CP) is implemented through a
  219.    straightforward client-server mechanism, in which there are very few
  220.    basic operations; registration, investigation, and deletion.
  221.    
  222.    In the registration process, a cyberspace client announces to a server
  223.    that it has populated a volume of space; in this sense, cyberspace
  224.    does not exist until it is populated: this is a corollary to
  225.    Benedikt'ís Principle of Indifference, which states: ìabsence from
  226.    cyberspace will have a cost.î
  227.    
  228.    The investigation process will be discussed in detail later in this
  229.    work. The basic transaction is simple: given a circumscribed volume of
  230.    space, return a set of all hosts which contribute to it. The reply to
  231.    such a transaction could be NULL or practically infinite (consider the
  232.    case where the request specifies a volume which describes the entirety
  233.    of cyberspace); this implies that level-of-detail must be implemented
  234.    within the transaction (and hence, within registration), in order to
  235.    optimize the process of investigation. Often, it is enough to know
  236.    cyberspace is populated, nothing more, and many other times, it is
  237.    enough to know only the gross features of the landscape, not the
  238.    particularities of it. In this sense, level of detail is a quality
  239.    intrinsic to cyberspace.
  240.    
  241.    Registration contains within it the investigation process; before a
  242.    volume can be registered successfully, ìpermissionî must be received
  243.    from cyberspace itself, and this must include an active collaboration
  244.    and authentication process with whatever other hosts help to define
  245.    the volume. This is an enforcement of the rule which forbids
  246.    interpenetration of objects within the physical world; it need not be
  247.    enforced, but unless it is observed in most situations, cyberspace
  248.    will tend toward being intrinsically disorienting.
  249.    
  250.    Finally, the deletion process is the logical inverse of the
  251.    registration process, where a volume defined by a client is removed
  252.    from cyberspace. These three basic transactions form the core of
  253.    cyberspace protocol, as implemented between the client and the server.
  254.    
  255.    
  256. Cyberspace Servers
  257.  
  258.    
  259.    
  260.    Cyberspace is a unified whole; therefore, from a transaction-oriented
  261.    point of view, every server must behave exactly like any other server
  262.    (specifically with respect to investigation requests). The same
  263.    requests should evoke the same responses. This would appear to imply
  264.    that every server must comprehend the ìtotalityî of cyberspace, a
  265.    requirement which is functionally beyond any computer yet conceived
  266.    of, or it places a severe restriction on the total content of
  267.    cyberspace. Both of these constraints are unacceptable, and a
  268.    methodology to surmount these constraints must be incorporated into
  269.    the cyberspace server implementation.
  270.    
  271.    The cyberspace server is implemented as a three-dimensional database
  272.    with at least three implemented operations; insertion, deletion, and
  273.    search. These correspond to the registration, deletion, and
  274.    investigation transactions. Each element within the database is
  275.    composed of at least three items of data; the volumetric identifier of
  276.    the space; the IP address of the host which ìmanifestsî within that
  277.    space; and the IP address of the cyberspace server through which it is
  278.    registered.
  279.    
  280.    The investigation transaction is the core of the server
  281.    implementation. Cyberspace servers use a repeated, refined query
  282.    mechanism, which iteratively narrows the possible range of servers
  283.    which are capable of affirmatively answering an investigation request
  284.    until the set exactly conforms to the volumetric parameters of the
  285.    request. This set of servers contains the entire possible list of
  286.    hosts which collaborate in creating some volume of cyberspace, and
  287.    will return a non-null reply to an investigation request for a given
  288.    volume of space. The complete details of the investigation algorythm
  289.    are beyond the scope of the current work and will be explained in
  290.    greater detail in a subsequent publication.
  291.    
  292.    An assumption implicit in the investigation algorithm is that
  293.    investigative searches have ìdepthî, that investigation is not
  294.    performed to its exhaustive limit, but to some limit determined by
  295.    both client and server, based upon the ìimportanceî of the request.
  296.    Registrations, on the other hand, must be performed exhaustively, but
  297.    can (and should) occur asynchronously.
  298.    
  299.    The primary side-effect of this methodology is that cyberspace is not
  300.    instantaneous, but is bounded by bandwidth, processor capacity, and
  301.    level of detail, in the form:
  302.    
  303.    [IMAGE]
  304.    
  305.    where c is a constant, the ìspeed limitî of cyberspace (as c is the
  306.    speed of light in physical space), l is the level of detail, b is
  307.    bandwidth of the internetwork, p is processor capacity, D is the
  308.    number of dimensions of the cyberspace, and r is the position within
  309.    the space. The function rho defines the "density" of a volume of
  310.    cyberspace under examination.
  311.    
  312.    This expression is intended to describe the primary relationships
  313.    between the elements which create cyberspace, and is not
  314.    mathematically rigorous, but can be deduced from Benedikt'ís Law.
  315.    
  316.    Finally, because cyberspace servers do not attempt to contain the
  317.    entirety of cyberspace, but rather, search through it, based upon
  318.    client transaction requests, it can be seen that the content of a
  319.    cyberspace server is entirely determined by the requests made to it
  320.    by its clients.
  321.    
  322.    One way to visualize the operation of cyberspace servers is with the
  323.    metaphor of Indra'ís Net, from Vedanta Hinduism; finely woven of
  324.    glittering jewels, each jewel reflecting every other.
  325.    
  326. Cyberspace and the World Wide Web
  327.  
  328.    
  329.    
  330.    Having defined, specified, and implemented an architecture which
  331.    provides a binding between spatio-location and data set location, this
  332.    architecture needs to be integrated with the existing WWW libraries so
  333.    that their functionality can be similarly extended. As ìlocationî is
  334.    being augmented by the addition of CP to WWW, it is the Universal
  335.    Resource Locator which must be extended to incorporate these new
  336.    capabilities.
  337.    
  338.    The URL, in its present definition, has three parts: an access
  339.    identifier (type of service), a host name (specified either as an IP
  340.    address or DNS-resolvable name), and a ìfilenameî, which is really
  341.    more of a message passed along to the host at the point of service.
  342.    Cyberspace Protocol fits well into this model, with two exceptions;
  343.    multiple hosts which collaborate on a space, and the identification of
  344.    a ìfilenameî associated with a registered volume of space.
  345.    
  346.    We propose a new URL of the following form:
  347.    
  348. cs://{pa.x.y.z}{pb.x.y.z}.../filename
  349.  
  350.    
  351.    
  352.    where {pn...} is a set of CP address elements.
  353.    
  354.    Resolution of this URL into a data set is a two-stage process: first
  355.    the client CP mechanism must be used to translate the given
  356.    spatio-location into a host address, then the request must be sent to
  357.    the host address. Two issues arise here; multiple host addresses, as
  358.    mentioned previously, and a default access mechanism for CP. If a set
  359.    of host addresses are returned by CP, a request must be sent to each
  360.    specified host; otherwise, the description of the space will be
  361.    incomplete. Ideally, all visualized WWW clients will implement a
  362.    threaded execution mechanism (with re-entrant WWW libraries) so that
  363.    these requests can occur simultaneously and asynchronously.
  364.    
  365.    A default access mechanism for CP within WWW must be selected. The
  366.    authors have chosen HTTP, for two reasons; it is efficient, and it is
  367.    available at all WWW servers. Nonetheless, this is not a closed issue;
  368.    it may make sense to allow for some variety of access mechanisms, or
  369.    perhaps a fallback mechanism; if one service is not present at a host,
  370.    another attempt, on another service, could be made.
  371.    
  372. Labyrinth
  373.  
  374.    
  375.    
  376.    It is now possible, from the previous discussion, to describe the
  377.    architecture and operation of a fully visualized WWW client. It is
  378.    composed of several pieces; WWW libraries with an integrated CP client
  379.    interface; an interpreter for an VRML-derived language which describes
  380.    object geometry, placement, and linkage; and a user interface which
  381.    presents a navigable ìwindow on the webî.
  382.    
  383.    The operation of the client is very straightforward, as is the case of
  384.    the other WWW clients. After launching, the client queries the ìspaceî
  385.    at ìhomeî, and loads the world as the axis mundi of the client's view
  386.    of the web. As a user moves through cyberspace, the client makes
  387.    requests, through CP, to determine the content of all spaces passed
  388.    through or looked upon. A great deal of design effort needs to be put
  389.    into the development of look-ahead caching algorithms for cyberspace
  390.    viewers; without them, the user will experience a discontinuous,
  391.    ìjerkyî trip through cyberspace. The optimal design of these
  392.    algorithms will be the subject of a subsequent work.
  393.    
  394.    At this time, visualized objects in WWW have only two possible
  395.    behaviors; no behavior at all, or linkage, through an attached URL, to
  396.    another data set. This linkage could be to another ìworldî (actually
  397.    another place in cyberspace), which is called a ìportalî, or it could
  398.    link to another data type, in which case the client must launch the
  399.    appropriate viewer. Labyrinth is designed to augment the functionality
  400.    of existing WWW viewers, such as NCSA Mosaic, rather than to supplant
  401.    them, and therefore does not need a well-integrated facility for
  402.    viewing other types of HTML documents.
  403.    
  404. Data Abstraction Protocols
  405.  
  406.    
  407.    
  408.    Cyberspace Protocol is a specific implementation of a general theory,
  409.    which has implications well beyond WWW. CP is the solution, in three
  410.    dimensions, of an N-dimensional practice for data set location
  411.    abstraction. Data abstraction places a referent between the ìnameî of
  412.    a data set locator and the physical location, allowing physical data
  413.    set location to become mutable.
  414.    
  415.    If an implementation were to be developed for the case where N = 1, it
  416.    would be an effective replacement Internet'ís Domain Name Service
  417.    (DNS), which maintains a static mapping of ìnamesî to IP addresses.
  418.    Any network which used a dynamic abstraction mechanism could mirror or
  419.    reassign hosts on a continuous basis (assuming that all write-through
  420.    mirroring could be maintained by the hosts themselves), so that the
  421.    selection of a host for a transaction could be made based upon
  422.    criteria that would tend to optimize the performance of the network
  423.    from the perspective of the transaction. It would also be easy to
  424.    create a data set which could ìfollowî its user(s), adjusting its
  425.    location dynamically in response to changes in the physical location
  426.    or connectivity of the user. In an age of wireless, worldwide
  427.    networking, this could be a very powerful methodology.
  428.    
  429. Conclusions
  430.  
  431.    
  432.    
  433.    This work attempts to outline the requirements for architectures which
  434.    can fully visualize WWW, and proposes solutions to the issues raised
  435.    by these requirements. While much further study needs to be done, this
  436.    work is meant to serve as a starting point for an understanding of the
  437.    subtleties of wide-area, distributed, visualized data sets.
  438.    
  439.    Labyrinth and Cyberspace Protocol are logical extensions to the World
  440.    Wide Web and Internet. Indeed, without the existence of WWW, neither
  441.    would be very useful immediately; they would operate, but lack
  442.    content, and individuals would hardly be compelled either to use them
  443.    or adapt their existing data sets to realize their new potentials.
  444.    Used together, they work to make both WWW and Internet inherently more
  445.    navigable, because they help to make Internet more human-centered,
  446.    adapting data sets to human capabilities rather than vice versa. This,
  447.    thus far, is the single largest contribution that ìvirtual realityî
  448.    research has offered to the field of computing; a human-centered
  449.    design approach that lowers or erases the barriers to usage by
  450.    creating user-interface paradigms which serve humans to the full of
  451.    their potential.
  452.    
  453.    Finally, network visualization marks the end of the ìfirst ageî of
  454.    networking, where protocols, services, and infrastructure dominated
  455.    the discourse within the field. In the ìsecond ageî of networking,
  456.    questions like data architecture and the inherent navigability of a
  457.    well- designed data set become infinitely more important than ìfirst
  458.    ageî questions; where ìhow do I find what Iím looking for?î becomes
  459.    more relevant than ìwhere did it come from?î
  460.    
  461. Acknowledgments
  462.  
  463.    
  464.    
  465.    The authors would like to thank the following individuals, who
  466.    contributed their own thoughts to the formation and development of the
  467.    ideas expressed in this work: Michael J. Donahue, Owen Rowley, Dr.
  468.    Stuart D. Brorson, Clayton Graham, Christopher Morin, Neil Redding,
  469.    James Curnow, Marina Berlin, Casey Caston and the Fugawi tribe.
  470.